Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.
In LTE, the Radio Resource Control (RRC) protocol is used to configure/setup and maintain the radio connection between a user equipment (UE) and a network node such as an evolved NodeB (eNB). When the UE receives an RRC message from the eNB, it will apply the configuration (the term “compile” may also be used to refer to the application of the configuration), and if this succeeds the UE generates an RRC complete message that indicates a transaction identity (ID) of the RRC message that triggered this response.
Since LTE-release 8, three Signalling Radio Bearers (SRBs), namely SRB0, SRB1 and SRB2 have been available for the transport of RRC and Non Access Stratum (NAS) messages between the UE and eNB. A new SRB, known as SRB1bis, was also introduced in rel-13 for supporting Data Over NAS (DoNAS) in Narrowband-Internet of things (NB-IoT).
SRB0 is for RRC messages using a Common Control Channel (CCCH) logical channel, and it is used for handling RRC connection setup, RRC connection resume and RRC connection re-establishment. Once the UE is connected to the eNB, i.e. RRC connection setup or RRC connection reestablishment/resume has succeeded, SRB1 is used for handling RRC messages, which may include a piggybacked NAS message, as well as for NAS messages prior to the establishment of SRB2, all using a Dedicated Control Channel (DCCH) logical channel.
SRB2 is for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower priority than SRB1, because logged measurement information and NAS messages may be lengthy and may cause the blocking of more urgent and smaller SRB1 messages. SRB2 is always configured by Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) after security activation.
E-UTRAN supports Dual Connectivity (DC) operation whereby a multiple Reception/Transmission (Rx/Tx) UE in RRC_CONNECTED mode is configured to utilize radio resources provided by two distinct schedulers, located in two eNBs, i.e. radio base stations, connected via a non-ideal backhaul over the X2 interface, see 3GPP 36.300 v. 13.0.0. “Non-ideal backhaul” implies that the transport of messages over the X2 interface between the network nodes may be subject to both packet delays and losses.
eNBs involved in DC for a certain UE may assume two different roles: an eNB may either act as a Master Node (MN), also referred to as Master eNB (MeNB), or as a Secondary Node (SN), also referred to as Secondary eNB (SeNB). In DC a UE is connected to one MN and one SN.
In LTE DC, the radio protocol architecture that a particular bearer uses depends on how the bearer is setup. Three bearer types exist: Master Cell Group (MCG) bearer, Secondary Cell Group (SCG) bearer and split bearers. RRC is located in the MN and SRBs are always configured as MCG bearer type and therefore only use the radio resources of the MN. When a node acts as an SN, the LTE DC solution does not have any UE RRC context of that UE and all such signalling is handled by the MN. FIG. 1 shows a LTE DC User Plane (UP) architecture.
In 3GPP, a study item on a new radio interface for 5G has recently been completed and 3GPP has now continued with the effort to standardize this new radio interface, often abbreviated by New Radio (NR).
LTE-NR DC, also referred to as LTE-NR tight interworking, is currently being discussed for rel-15.
In this context, the major changes from LTE DC are                The introduction of a split bearer from the SN known as SCG split bearer. The SN in this case is also referred to as SgNB, secondary gNB, where gNB denotes an NR base station.        The introduction of split bearers for RRC.        The introduction of a direct RRC from the SN known as SCG-SRB or direct SRB.        
FIGS. 2 to 4 show the User Plane (UP) and Control Plane (CP) architectures for LTE-NR tight interworking.
It should be appreciated that embodiments herein apply to different scenarios where the MN and SN nodes can apply various radio interface technologies. The MN node can apply e.g. LTE or NR, and the SN node can also use either LTE or NR without departing from the main concept of embodiments herein. Other technologies could also be used over the radio interface. The 3GPP technical report TR 38.304 v. 0.0.3 includes various scenarios and combinations where the MN and SN are applying either NR, LTE or both.
For the first phase of 5G standardization and 5G deployment, the most likely scenario is that MN will apply LTE, and the SN will apply the new radio interface, denoted NR, currently being under standardization. Thus, we focus on this scenario and use the term MeNB and SgNB for the rest of this description.
The following terminologies are used throughout this text to differentiate different dual connectivity scenarios:                DC: LTE DC, i.e. both MN and SN employ LTE.        EN-DC: LTE-NR dual connectivity where LTE is the master and NR is the secondary.        NE-DC: LTE-NR dual connectivity where NR is the master and LTE is the secondary.        NR-DC (or NR-NR DC): both MN and SN employ NR.        Multi-RAT DC (MR-DC): a generic term to describe where the MN and SN employ different radio access technologies (RAT). EN-DC and NE-DC are two different example cases of MR-DC.        
As already mentioned above, the DC approach introduced for 5G standardization includes a solution for split bearers for SRBs, see FIGS. 3 and 4. The intent of introducing such “RRC diversity” is to enable e.g. better mobility robustness and improved message delivery between the infrastructure and the UE. For example, it is then possible to send a handover message or any other reconfiguration message over the best link, even if one of either the link or links to the MeNB (or SgNB) has deteriorated significantly. It is also possible to send duplicates of the same message over both MeNB and SgNB to achieve a better success-rate and faster delivery of the concerned message; in case the links are error prone. Such benefits of “RRC diversity” are not available in the current LTE DC solution, and 3GPP has therefore undertaken the challenge to enable such RRC diversity. Having RRC diversity may prove particularly important for ultra-reliable connections with low latency, often called Ultra Reliable Low Latency Communication (URLLC).
As can be seen in FIG. 4, RRC messages generated and/or transmitted from the MN can be sent either via the MeNB, or relayed over an X2 interface to the SgNB. The messages received over the different paths in the UE are then combined to the LTE Packet Data Convergence Protocol (PDCP) and then forwarded to the LTE RRC receiving entity and processed further. In the uplink, the UE generates LTE RRC messages that the UE may transmit either over the NR radio interface towards the SgNB or via the MN node using LTE technology. Messages received in the SgNB are then forwarded over an X2 interface towards the MeNB node.
One of the main reasons behind the introduction of SCG SRB between the UE and SN is that there may be SCG reconfiguration scenarios where SN can configure the UE directly without the need for coordination with the MN. This is for cases such as intra-SN mobility, measurement configurations/reporting related to the intra-SN cells, etc. Intra-SN meaning within SNs. Thus, it has been agreed in 3GPP that SCG SRB will support a (subset) of the functionalities, namely: RRCConnectionReconfiguration, in the DL; and RRCConnectionReconfigurationComplete and MeasurementReport in the UL.
Another control signalling mechanism, in addition to SCG SRB and split SRBs, in LTE-NR tight interworking is using embedded RRC and is also illustrated in FIG. 4. Embedded RRC is employed for two cases:                1. When SCG SRB is not available.        2. The UE has to be configured with settings that affect both the NR and LTE legs, i.e. a co-ordination is required, even if direct SRB is available.        
For the first case, the SgNB sends the RRC message to the MeNB via the X2 interface, which the MeNB then embeds in its own RRC message and sends via SRB1, which could be split or not. The UE then extracts the embedded NR RRC message from the container MeNB RRC message and apply the configurations on the NR leg. In the UL direction, the UE embeds the NR RRC messages in an LTE RRC message towards the MeNB, and the MeNB will extract the embedded NR RRC message from this and forwards it to the SgNB.
For the second case, i.e. messages/configurations that require co-ordination between the MeNB and SgNB, e.g. inter (i.e. between different)-RAT measurement configurations, settings affecting buffer sizes which the UE has to allocate to the NR and LTE legs without exceeding the total buffering capability of the UE, etc., the SgNB node can send the NR configurations, the MeNB and SgNB can negotiate the final configurations since it affects the settings of both legs, and the final configuration for the NR leg is sent to the UE via an LTE RRC message that contains the embedded NR RRC message, wherein the final embedded NR RRC message still being generated by the SN.
In LTE, a UE considers a radio link failure (RLF) to be detected when:                i. Upon detecting a certain number of out of sync (OOS) indications from the lower layers associated with a Primary Cell (PCell) within a given time, or        ii. upon random access problem indication from Media Access Control (MAC), or        iii. upon indication from Radio Link Control (RLC) that the maximum number of retransmissions has been reached for an SRB or for a data radio bearer (DRB).        
When RLF is detected, the UE prepares an RLF report, which includes, among other information, the measurement status of the serving and neighbour cells at the moment when RLF was detected, goes to IDLE mode, selects a cell following IDLE mode cell selection procedure wherein the selected cell could be the same serving node/cell or another node/cell, and starts the RRC re-establishment procedure, with a cause value set to rlf-cause.
In the case of LTE DC, the RLF detection procedure is similar to what was described above except that for (i), we are concerned only the PCell of the MN, the MAC in (ii) is the MCG MAC entity and the RLC in (iii) is the MCG RLC and the DRB in (iii) corresponds to MCG and MCG-split DRBs.
On the other hand, failure on the secondary side, known as SCGFailure, is detected by:                a) upon detecting radio link failure for the SCG, in accordance with i, ii and iii above, i.e. replace PCell for primary secondary cell (PSCell), MCG MAC for SCG MAC, and MCG/MCG-Split DRB for SCG DRB, or        b) upon SCG change failure, i.e. not able to finalize SCG change within a certain duration after the reception of an RRC connection reconfiguration message instructing the UE to do so, or        c) upon stopping uplink transmission towards the PSCell due to exceeding the maximum uplink transmission timing difference when powerControlMode is configured to 1.        
Upon detecting SCGFailure, the UE sends an SCGFailureInformation message towards the MN, which also includes measurement reports, and the MN can either release the SN, change the SN/Cell, or reconfigure the SCG. Thus, a failure on the SCG will not lead to a re-establishment to be performed on the MCG.
3GPP has agreed to adopt the same principles in the context of LTE-NR interworking, i.e. re-establishment in the case of RLF on the master leg and recovery via SCGFailureInformation and SN release/change/modification in case of RLF on the secondary leg. Specifically, it has been agreed:
Upon SgNB Failures, UE Shall:
                Suspend all SCG DRBs and suspend SCG transmission for MCG split DRBs, and SCG split DRBs;        Suspend direct SCG SRB and SCG transmission for MCG split SRB;        Reset SCG-MAC;        Send a SCGFailureInformation message to the MeNB with corresponding cause values.        
The problem with the existing solution is in the case the SCG failure in the UE occurs at the same time there is an ongoing SCG reconfiguration from the SN. This can result in two types of problems:    1. When should the UE resume the SCG link which is suspended at the detection of SCG failure.    2. What is the last valid UE configuration according to the UE and network.            If the network and UE does not have an agreement on the last valid UE configuration the network is forced at the next reconfiguration to send the full UE configuration which may be a very large message.        If the network and UE do have an agreement on the last valid UE configuration the network can at the next reconfiguration use delta signalling, which is in comparison with the valid UE configuration, which is more efficient.        
Embodiments herein are related to the case when SCG SRB is not configured and all SN RRC messages are delivered embedded with the MCG SRB, or the case where SCG SRB is configured and the last SCG reconfiguration that was sent to the UE just before SCG failure was sent via embedded RRC, e.g. due to a need for co-ordination with the MCG, or via the SCG SRB.
Consider a situation where the UE has SCG_configuration_version1, and the SN has sent SCG_configuration_version2 via embedded SRB. Furthermore, an SCG failure is detected at the UE, e.g. due to RLF on the PSCell, due to max number of RLC retransmissions on an SCG DRB, etc.
Case 1: The MN receives the SCGFailureInformation before it has managed to send the MCG RRC message that embeds the SCG_configuration_version2 to the UE.
Case 2: The MN has started sending the MCG RRC message that embeds the SCG_configuration_version2 to the UE when it receives the SCGFailureInformation, but it has not finalized it yet, e.g. part of the message was still not scheduled, part of the message was being re-transmitted due to lower layer issues)
Case 3: The MN has successfully sent the MCG RRC message that embeds the SCG_configuration_version2 to the UE but while waiting for the complete message for that configuration, an SCG failure was detected in the UE.
Case 3a: while the UE was still applying the SCG_configuration_version2.
Case 3b: the UE has applied the SCG_configuration_version2, and has sent the complete message to the SN embedded with an uplink (UL) message to the MN, but the message has not been received at the MN yet.
Case 3c: same as case 3b, but the MN has received the UL message from the UE, but has not delivered the lower layer acknowledgement (ACK), i.e. the UE still not sure if the message has been delivered to the MN.
In all cases, a situation may arise where the SN and the UE might have different SCG configurations. That is, when the MN tries to get the UE's SCG configuration from the SN, the SN will not be sure to provide SCG_configuration_version1 or SCG_configuration_version2. The SN will not know whether the UE has applied the SCG_configuration_version2 or not as it has not received the complete message.
In case 1, if the MN refrains from forwarding the SCG_configuration_version2, since it knows that the UE has experienced SCG failure, the configuration of the UE will remain SCG_configuration_version1.
On the other hand, if the MN forwards the SCG_configuration_version2 anyways to the UE, the UE will try to apply the configuration. In LTE DC, such a reception of a reconfiguration would have been interpreted by the UE as a response by the network to the SCG failure that it has sent earlier. In this case the UE may decide to resume the SCG link which is typically suspended at SCG failure. But since this message was generated by the SN before the SCG failure was detected/reported, there may not be mobilityControlInfoSCG (for SCG change) or release indicator (SCG release) meaning it is unlikely that the resume of SCG link would work since UE is still in the same SCG cell. However, if SCG_configuration_version2 was a mobility configuration from the SN, e.g. change of the PScell, then this could also be mistaken by the UE as a response for the SCGFailure Report that has just been sent. The mobility command from the SN might have actually solved the SCG issue, but since the MN is not aware of it, it will try to handle the SCG failure. This might result in:                Unnecessary signalling: If the MN decides to keep the SN, then it may forward the measurement results to the SN, along with an SgNB modification request, for example, or in a separate message, which will probably result in no actual modification from the SN as the SN knows that it has just applied the mobility.        Unnecessary SN change or release: The MN may decide to change the SN, even if the UE has actually successfully recovered the SCG, e.g. changed the PScell. The situation is the same in case the MN decides to release the SN if there was no other SN with a better signal quality.        
The situation in case 2 is the same as in Case 1, i.e. the UE has not received the reconfiguration message yet, so all the above consideration for case 1 still applies.
In case 3, regardless of the UE's state (i.e. case 3a, 3b, 3c), it is not completely clear also what the UE behavior will be. But assuming a proper UE implementation, we can assume that the UE will not interrupt the ongoing application of the configuration if SCG failure happens. Thus, cases 3a and 3b are effectively the same. And from the UE's point of view, case 3c is also similar to case 3a and 3b in that it is not sure whether the complete message was received at the MN or not. However, from the network's point of view, case 3b and 3c are different because in case 3c, the network knows the UE has applied the latest configurations. Since both the SCG failure information as well as the complete message are sent via SRB1, even in case 3a/3b, the SCG failure information will be scheduled/sent after the complete message. As such, the network and the UE has the same configuration, e.g. SCG_configuration_version2, but the SN is not yet aware of it since the MN has not forwarded the complete message to the SN yet. and also like in cases 1 and 2, that this latest reconfiguration might have already resolved the SCG failure but the MN is not aware of it and thus will try to resolve a problem that is already taken care of.
The last SCG reconfiguration may be sent via embedded SRB, but also sent via SCG SRB.
Case 4: The SCG_configuration_version2 was sent via the SCG SRB
Case 4a: the UE did not receive the SCG_configuration_version2 due to the SCG failure.
Case 4b: the UE has received the reconfiguration message with the SCG_configuration_version2, but it has not managed to send the complete message for that
In case 4, the problem is that the SN node does not know if the UE has applied the SCG_configuration_version2 or not.
In R2-1710622 “Further details on SRB3 handling” by Intel Corporation it was proposed that the UE should include a transaction identity (ID), in the SCG Failure message, of the last RRC SCG configuration that it got prior to the failure. And the MN may include this information when requesting the latest SCG configuration from the SN. In this way, at least the network will know which configuration the UE considers valid at the time of SCG failure. However, there are still issues with this solution:                The SCGFailure reporting and the forwarding of the embedded SCG_configuration_version2 may happen at the same time, e.g. during a same Transmission Time Interval (TTI). Thus, there is still a chance that the UE will have received the latest configuration but has indicated the previous configuration in the SCG Failure.        If the embedded SCG_configuration_version2 has not been sent before the SCGFailure report was received at the MN, then the MN may discard this message and request the latest SCG configuration from the SN (indicating the previous transaction ID). This will have the same downside as described above, i.e. the MN trying to handle the problem that is already solved by the SN.        The solution requires the UE to keep track of SCG configuration transaction IDs even after the configurations has been applied successfully, just in case a failure happens during the next reconfiguration.        
Thus, there is still an issue for coordinating which SCG_configuration is used at the UE.